IAM アクセスアナライザー と IAM アクセスアドバイザー をもう二度と混同しないために絵をかいて理解してみた
コンバンハ、千葉（幸）です。
突然ですが問題です。
あなたは企業の AWS 管理者です。IAM アクセスアナライザー もしくは IAM アクセスアドバイザー の機能を活用して、適切なアイデンティティ管理に役立てようとしています。
次に示す選択肢のうち、上記の機能を適切に活用している（誤った記述がない）取り組みを表すものを、すべて 挙げてください。（10点）
- 開発ベンダーが利用する資材格納用の S3 がある。当該 S3 バケットが意図せぬ外部エンティティからアクセス可能となっていないか、 IAM アクセスアナライザーを用いて確認した。
- 90日以上いずれの AWS サービスへもアクセスを行なっていない IAM ユーザーは一時的に無効化したい。IAM アクセスアドバイザーの通知機能を有効化し、該当ユーザーが検知されたら SNS 経由で E メールを受信できるように設定した。
- IAM アクセスアナライザーによる分析が行われた結果、開発ベンダーに割り当てている IAM ロールへの Finding が発生した。ロールに割り当てているカスタマー管理ポリシーを見直したところ外部エンティティへのアクセスが可能であったため、当該箇所を修正し、Finding を解決済みステータスに遷移させた。
- エンドユーザーへの通知に Amazon SNS を利用している。SNS トピックポリシーで許可されているプリンシパルが自アカウントのみであるか、 IAM アクセスアナライザーを用いて確認した。
- S3 向けの VPC エンドポイントをフルアクセスからカスタムに変更しようとしている。変更後のポリシーが想定通りの挙動を示すかを事前に確認するため、 IAM アクセスアドバイザーでシミュレートを行った。
- 複数の IAM ユーザーが引き受ける（assume）ことができるネットワーク管理者用の IAM ロールがある。当該ロールが過去 30 日間にどのユーザーから assume されたかの履歴を IAM アクセスアドバイザーで確認し、棚卸しを行なった。
- 管理者用の IAMロールには現在
AdministratorAccessをアタッチしているが、必要最小限のポリシーに制限したい。IAM アクセスアナライザーを用いて過去 180 日間の API の実行履歴を分析し、レコメンドされたポリシーを適用した。
……はい。という問題です。
暇な方は、少し考えてみてください。暇じゃない方は、無視していただいて問題ありません。
いくつか補足しておきます。
- 今後アップデートがあるかもしれないので、2020年8月現在の仕様に則るものとしてください
- 私が勝手に考えた問題なので、覚えても試験対策にはなりません
- ツッコミどころがあれば、優しく、そして徐に指摘してください
IAM アクセスアナライザーと IAM アクセスアドバイザー、それぞれでできることを正しく理解している方は問題なく回答が導けたでしょう。
私はと言うと、ほんの一週間前まではろくに区別もついていないし、何ができるのかもよく分かっていないという状態でした。
そうなるともう図解して脳に刻みつけるしかないので、いつものように絵を描きました。ぜひ皆さんの脳にも刻み付けていってください。
回答は少し後に載せています。
目次
先に結論
IAM アクセスアドバイザーはこれです。
IAM アクセスアナライザーはこれです。
以上です。もうほとんど言いたいことは言い終わりました。
でももう少しだけ補足します。
IAM Access Advisor とは
IAM アクセスアドバイザーは、サービスやリソースの名称ではありません。
以下のような API を使用して、IAM リソースがアクセス可能なサービスや過去のアクセス履歴を参照すること、あるいはその機能そのものを アクセスアドバイザーと呼びます。
GenerateServiceLastAccessedDetailsGetServiceLastAccessedDetailsGetServiceLastAccessedDetailsWithEntitiesListPoliciesGrantingServiceAccess
当初はマネジメントコンソールから参照する場合のみ「アクセスアドバイザー」と呼称されるのかと考えていましたが、API を実行する手段は問わないようです。
この機能を使うことで、各種 IAM リソースの権限の整理に役立ちます。アクセス権があるけれども一定期間アクセスしていない、というサービスがあれば、割り当てているポリシーを見直すきっかけとなるでしょう。最小権限を割り当てることがベストプラクティスとされていますので、定期的にチェックしたい項目です。
他にも、意図せぬ AWS サービスにアクセス可能となっていないかの確認であったり、過去一定期間でアクセスした AWS サービスの履歴の表示であったり、簡易的な監査の用途で使うこともできます。具体的にどうすればいい、とアドバイスをくれるものではないですが、判断に必要な情報を提供してくれるものです。
アクセスアドバイザーで取得できる情報
IAM リソースごとに微妙に異なりますが、基本的には アクセス可能なサービスと、過去のアクセス履歴が取得できます。
アクセス可能なサービスは、アタッチされている IAM ポリシー（もしくはポリシー自身）が権限を持っているかどうかのみで評価されます。Organizations の SCP や Permissions boundary で制限されていたとしても、「アクセス可能でない」という評価に変わるわけではありません。
過去のアクセス履歴で確認できるのは、AWS サービスレベルでの最終アクセス時刻です。リソースレベルやアクションレベルといった細かい単位での確認はできません。（例外的に、Amazon S3 だけはアクションレベルでの記録に対応しています。）
IAM エンティティである ユーザー と ロール に対してアクセスアドバイザーを実行する場合、考え方はシンプルで、それら自身の「アクセス可能なサービス」「過去のアクセス履歴」が取得できます。
グループ や ポリシー の場合、それら自身がアクセスを行うわけではないため、取得できる情報は以下の考えかたとなります。
- グループ：
- グループに所属するユーザーがアクセス可能なサービス
- グループに所属するユーザーの最終アクセス時刻、およびアクセスしたユーザーの合計数
- ポリシー：
- 当該ポリシーの内容でアクセス可能なサービス
- 自身がアタッチされたユーザー（グループからの継承含む）もしくはロールの最終アクセス時刻、およびアクセスしたエンティティの合計数
マネジメントコンソールでのアクセスアドバイザー
見え方を確認しましょう。
ユーザーの場合。
ロールの場合。
グループの場合。
ポリシーの場合。
暇な方は、アクセスアドバイザーを参照した後に CloudTrail を覗いてみてください。上述した API を実行したイベントが確認できるかと思います。楽しいです。
AWS CLI でのアクセスアドバイザー
つい先日試したエントリがありますので、こちらをご参照ください。
また、アクセスアドバイザー全般に関する詳細な仕様は以下を確認してください。
IAM Access Analyzer とは
IAM アクセスアナライザーはれっきとした AWS サービスの一つです。
サービス名は IAM Access Analyzer で、サービスの名前空間は access-analyzer です。
サービス IAM Access Analyzer に属するリソースには アナライザー と アーカイブルール があります。
アナライザーを作成すると、アナライザーは「 IAM Access Analyzer のサービスにリンクされたロール」に割り当てられた権限を用いて、対象のリソースタイプに対して分析を開始します。
分析を行うことで、外部からのアクセスが可能となっているリソースを確認できます。
アクセスアナライザーでできること
アクセスアナライザーを有効化することで、対象のリソースタイプが信頼ゾーンの外部のエンティティからアクセス可能な状態になっていないかを確認できます。
信頼ゾーンは、自身のアカウントか、Organizations 全体のいずれかです。
外部のエンティティからアクセス可能かどうか、という判定は各リソースのリソースベースポリシーに含まれている内容を基に行われます。
現時点で以下のリソースタイプが対象としてサポートされています。
- Amazon Simple Storage Service バケット
- AWS Identity and Access Management ロール
- AWS Key Management Service キー
- AWS Lambda の関数とレイヤー
- Amazon Simple Queue Service キュー
AWS IAM Access Analyzer とは - AWS Identity and Access Management
アナライザーにより外部エンティティからアクセス可能なリソースが検知された場合、それは Finding（結果）という単位で管理されます。
Finding は以下のいずれかのステータスを持ちます。
- アクティブ：検知されたままの状態です
- アーカイブ済み：検知された内容が意図通りであればアーカイブすることができます
- 解決済み：検知対象のリソースのポリシーを修正することで解決済みにできます
事前にアーカイブルールを定義しておくことで、条件に合致した Finding を自動的にアーカイブ済みに遷移させることができます。
Finding が発生した場合、EventBridge と連携させて通知を行うこともできます。
使用イメージについては以下を参照してください。
マネジメントコンソールでのアクセスアナライザー
どのように見えるかを確認していきましょう。 IAM サービス画面のうち、以下の 4つがアクセスアナライザーに関する画面です。
[ Access Analyzer ] 画面です。
[ アーカイブルール ] 画面です。
[ アナライザー ] 画面です。
[ 設定 ] 画面です。
アクセスアナライザーを完全に理解できましたね。
冒頭の問題の答え
冒頭の問題の答えです。「適切なものをすべて挙げろ」という問題なので、「1.のみ」を挙げた方が正解です。
「1.」以外はすべて誤った記述です。選択肢が 7つもあるのに適切な記述が 1つだけとは、出題者の意地の悪さが分かりますね。
- 開発ベンダーが利用する資材格納用の S3 がある。当該 S3 バケットが意図せぬ外部エンティティからアクセス可能となっていないか、 IAM アクセスアナライザーを用いて確認した。
- IAM アクセスアナライザーでできることに合致しているので正しい記述です。
- 90日以上いずれの AWS サービスへもアクセスを行なっていない IAM ユーザーは一時的に無効化したい。IAM アクセスアドバイザーの通知機能を有効化し、該当ユーザーが検知されたら SNS 経由で E メールを受信できるように設定した。
- IAM アクセスアドバイザーに通知機能はないため誤りです。この記述のような形で通知が欲しい場合は作り込みを行う必要があります。
- IAM アクセスアナライザーによる分析が行われた結果、開発ベンダーに割り当てている IAM ロールへの Finding が発生した。ロールに割り当てているカスタマー管理ポリシーを見直したところ外部エンティティへのアクセスが可能であったため、当該箇所を修正し、Finding を解決済みステータスに遷移させた。
- IAM アクセスアナライザーが分析の対象とするのは信頼ポリシー（リソースベースポリシー）のため、誤りです。カスタマー管理ポリシーはアイデンティティベースポリシーであり、修正を加えても Finding の結果に影響はありません。
- エンドユーザーへの通知に Amazon SNS を利用している。SNS トピックポリシーで許可されているプリンシパルが自アカウントのみであるか、 IAM アクセスアナライザーを用いて確認した。
- IAM アクセスアナライザーがサポートするリソースタイプに SNS トピックは含まれないため誤りです。
- S3 向けの VPC エンドポイントをフルアクセスからカスタムに変更しようとしている。変更後のポリシーが想定通りの挙動を示すかを事前に確認するため、 IAM アクセスアドバイザーでシミュレートを行った。
- IAM アクセスアドバイザーにシミュレート機能はないため誤りです。加えて、VPC エンドポイントはアドバイザーの対象ではありません。
- 複数の IAM ユーザーが引き受ける（assume）ことができるネットワーク管理者用の IAM ロールがある。当該ロールが過去 30 日間にどのユーザーから assume されたかの履歴を IAM アクセスアドバイザーで確認し、棚卸しを行なった。
- IAM アクセスアドバイザーで参照できる情報とはマッチしないため誤りです。 IAM ロール「が」アクセスした 「サービスレベル」の履歴であれば確認できます。
- 管理者用の IAMロールには現在
AdministratorAccessをアタッチしているが、必要最小限のポリシーに制限したい。IAM アクセスアナライザーを用いて過去 180 日間の API の実行履歴を分析し、レコメンドされたポリシーを適用した。- もう何もかも違うので誤りです。
「できないこと」でなく「できること」に目を向けた問題を作れよ！と思わなくもないですが、できないことを先に抑えることで理解が進むこともあるかなと考えてます。
終わりに
10 点獲得された方はおめでとうございます。特に意味はありませんが、ぜひ強く生きてください。
他にも IAM ポリシーシミュレーター というものがありますが、これは別に似ていなかったですね。
以上、千葉（幸）がお送りしました。
